home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-tpix-transit-01.txt < prev    next >
Encoding:
Text File  |  1993-07-08  |  11.8 KB  |  450 lines
  1.  
  2. TP/IX Working Group                                        R. L. Ullmann
  3. Internet Draft                              Process Software Corporation
  4.                                                            June 30, 1993
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.                    Transit Policy Routing in TP/IX
  12.  
  13. 1  Status of this Memo
  14.  
  15. This memo discusses the requirements of transit policy routing, and
  16. methods of implementation using TP/IX-IPv7 and RAP.  It is
  17. informational.
  18.  
  19. This document is an Internet Draft.  Internet Drafts are working
  20. documents of the Internet Engineering Task Force (IETF), its Areas,
  21. and its Working Groups.  (Note that other groups may also distribute
  22. working documents as Internet Drafts).
  23.  
  24. Internet Drafts are draft documents valid for a maximum of six months.
  25. Internet Drafts may be updated, replaced, or obsoleted by other
  26. documents at any time.  It is not appropriate to use Internet Drafts
  27. as reference material or to cite them other than as a "working draft"
  28. or "work in progress."
  29.  
  30. Please check the I-D abstract listing contained in each Internet Draft
  31. directory to learn the current status of this or any other Internet
  32. Draft.
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Ullmann            DRAFT: expires December 29, 1993            [page  1]
  65.  
  66. Internet draft       Transit Policy Routing in TP/IX       June 30, 1993
  67.  
  68.  
  69. 2  Contents
  70.  
  71.         1       Status of this Memo  . . . . . . . . . . . . . . . . 1
  72.         2       Contents . . . . . . . . . . . . . . . . . . . . . . 2
  73.         3       Introduction . . . . . . . . . . . . . . . . . . . . 3
  74.         4       Outline of requirements  . . . . . . . . . . . . . . 3
  75.         4.1       Source selection . . . . . . . . . . . . . . . . . 4
  76.         4.2       USA legal requirement  . . . . . . . . . . . . . . 4
  77.         5       Basic service offering scenario  . . . . . . . . . . 5
  78.         5.1       Routes offered by IXCs . . . . . . . . . . . . . . 5
  79.         5.2       Cost-based selection . . . . . . . . . . . . . . . 5
  80.         5.3       Per-datagram route identification  . . . . . . . . 6
  81.         6       Transit Network Identifier . . . . . . . . . . . . . 6
  82.         7       References . . . . . . . . . . . . . . . . . . . . . 7
  83.         8       Author's Address . . . . . . . . . . . . . . . . . . 7
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128. Ullmann            DRAFT: expires December 29, 1993            [page  2]
  129.  
  130. Internet draft       Transit Policy Routing in TP/IX       June 30, 1993
  131.  
  132.  
  133. 3  Introduction
  134.  
  135. The future Internet must support routing under a number of policy
  136. constraints, some of which will appear very arbitrary from a technical
  137. standpoint, being based on political regulations and such mundane
  138. issues as minimizing the monentary cost of specific traffic flows.
  139.  
  140. One specific requirement is the ability of a traffic source to select
  141. the transit network(s) to be used for specific subsets of the offerred
  142. traffic.
  143.  
  144. While this memo discusses the use of RAP as the routing protocol to
  145. provide the policy selection required, this is not exclusive:  any
  146. routing protocol with the proper features may be used over TP/IX-IPv7
  147. to meet the requirements.
  148.  
  149. Note that while the problems and methods describe the relationship
  150. between commercial local-exchange and inter-exchange carriers and
  151. their customers, the discussion applies equally well to the cost
  152. management problems that occur within large organizations and within
  153. the network service providers themselves.
  154.  
  155. 4  Outline of requirements
  156.  
  157. The considerations for selection of IXCs (inter-exchange carriers, in
  158. terminology derived from USA usage) include cost, availability, local
  159. policies (such as contracts with IXCs), non-local policies (national
  160. rules on transit traffic), and the human desire to control what is
  161. controllable:  e.g., management says we are to use carrier X for all
  162. EDI traffic.
  163.  
  164. These considerations can vary rapidly, and multiple selection
  165. decisions may be in use simultaneously.  A particular source may at
  166. the same time be routing some traffic via one carrier, and some via
  167. another; there may be dozens of carriers involved.
  168.  
  169. Cost can vary in real time, and may also be affected by volume
  170. discount programs (known to the customer and the IXC, but not known to
  171. the local exchange).  In particular, IXCs may offer pricing in real
  172. time, in response to network load or any other factor the IXC wants to
  173. take into account.
  174.  
  175. Availability is subject to change:  a major failure within one IXC
  176. will result in traffic being transferred to others.  It is best if
  177. this is done by the customer selecting routes, not by "splashing." At
  178. the same time, this is going to trip overload event triggers in other
  179. IXCs as traffic is transferred, and the results of those trips
  180. (premium pricing, rate limitations) must be communicated to the users.
  181.  
  182. A good description of some related problems can be found in [Perl92]
  183. pages 245 ff.
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192. Ullmann            DRAFT: expires December 29, 1993            [page  3]
  193.  
  194. Internet draft       Transit Policy Routing in TP/IX       June 30, 1993
  195.  
  196.  
  197. 4.1  Source selection
  198.  
  199. In the following diagram A and B are traffic sources within a customer
  200. network, C is the "border" router within the customer's management, N
  201. is the first router within the local exchange.
  202.  
  203. D-F is one transit network, and E-G is another.  The destination of
  204. the traffic is X (possibly with its own set of local exchange and
  205. internal routers.) Each router may, of course, be a number of routers
  206. in some locally defined topology; they are abstracted here as one.
  207.  
  208.  
  209.  
  210.                 A                D ------ ... ------ F
  211.                  \              /                     \ 
  212.                   \            /                       \
  213.                    \          /                         \
  214.                     C ------ N                           X
  215.                    /          \                         /
  216.                   /            \                       /
  217.                  /              \                     /
  218.                 B                E ------ ... ------ G
  219.  
  220.  
  221.  
  222.  
  223. Router C must be able to acquire knowledge in real time of the
  224. availability and costs of the transit networks, and be able to select
  225. one for each datagram forwarded to router N.  C must also be able to
  226. offer this same degree of flexibility in network selection to A and B.
  227.  
  228. Likewise, router N must be able to determine which transit network to
  229. use for each datagram received from C, and be able to offer the routes
  230. to C.
  231.  
  232. All of the decisions that may possibly be affected by policy must be
  233. made available to the customer's equipment.
  234.  
  235. 4.2  USA legal requirement
  236.  
  237. In particular, it is not only unacceptable, but actually illegal in
  238. the USA for a local provider to make a decision selecting an
  239. inter-exchange provider on behalf of the customer.  The present
  240. providers of the Internet service in the USA avoid this by using lines
  241. leased from the local provider (regional Bell operating company (RBOC)
  242. or other local exchange company (LEC)); this effectively excludes the
  243. RBOCs and other LECs from the business of providing Internet service
  244. under the present (IPv4) routing paradigm.
  245.  
  246. To meet the equal access requirements, the LECs must provide the
  247. ability to pre-subscribe a line (not difficult, even with IPv4,
  248. although it may cause troublesome interactions with IPv4 routing
  249. protocols).  The LECs must also provide "per-call" transit network
  250. selection.  In a connectionless network layer service, this means
  251. per-datagram selection.
  252.  
  253.  
  254.  
  255.  
  256. Ullmann            DRAFT: expires December 29, 1993            [page  4]
  257.  
  258. Internet draft       Transit Policy Routing in TP/IX       June 30, 1993
  259.  
  260.  
  261. While this requirement is specific to the USA, other countries can be
  262. expected to establish similar requirements as they open their telecoms
  263. markets to direct competition.
  264.  
  265. 5  Basic service offering scenario
  266.  
  267. Given the complexity of the requirements, it is clear that no
  268. standardized structure for making decisions within the (provider)
  269. network on the basis of requests for grades of service is going to be
  270. adequate.  Individual "calls", i.e.  flow setups, can demand specific
  271. resources, but the general decision making must be offered to the
  272. customer equipment, where a decision of arbitrary complexity on an
  273. arbitrary set of constraints can be made.
  274.  
  275. The method used in IPv7 and RAP to provide this level of service is
  276. described in the following sections.
  277.  
  278. 5.1  Routes offered by IXCs
  279.  
  280. Each IXC offers a set of routes via its interconnection points with
  281. the LECs.  Each route describes a particular aggregation of
  282. destinations; by country, AD, whatever hierarchy may be established
  283. with an AD, or individual networks.  In some cases, it may be for
  284. individual "hosts"; addresses of well-known service offerings, along
  285. the lines of (the USA) "800" numbers, which can be located anywhere,
  286. via any provider.
  287.  
  288. There may also be routes offered for individual hosts that are roaming
  289. in the cellular/wireless service; this may ordinarily be via different
  290. interconnection points, and then aggregated into the general service.
  291.  
  292. Each route carries a tag identifying the transit provider.  It also
  293. carries descriptors of cost and other attributes of the path(s)
  294. offered.  Some of the routes may carry the target attribute:  i.e.,
  295. the LEC is directed to offer the route only to one specific customer
  296. or aggregation.
  297.  
  298. The LECs then offer these routes to their customers, subject to any
  299. local policies of the LEC or pre-subscription of the customer.  The
  300. offered routes carry forward route identifiers assigned by the LEC
  301. router.
  302.  
  303. 5.2  Cost-based selection
  304.  
  305. The router at or near the traffic source can then make a decision to
  306. use one or more particular routes for a destination.  This decision
  307. may be based on cost, as viewed by the policies of its owner.
  308.  
  309. A pure monentary-cost based decision may result in very frequent
  310. changes of transit network selection, as the networks compete in real
  311. time for traffic.  Some attention may need to be given to maintaining
  312. network stability in this case.
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320. Ullmann            DRAFT: expires December 29, 1993            [page  5]
  321.  
  322. Internet draft       Transit Policy Routing in TP/IX       June 30, 1993
  323.  
  324.  
  325. 5.3  Per-datagram route identification
  326.  
  327. The router making a decision then identifies the route desired by
  328. copying the forward route identifier from RAP into the FrID field in
  329. the datagrams.
  330.  
  331. For flow, or full connection-based circuit setup, the source router
  332. uses the FrID in the setup exchange, and then records the flow ID or
  333. circuit LCN (logical channel number) in the FrID field of the IPv7
  334. datagram.  If RAP is being used as the setup protocol, this reduces to
  335. the same operation.
  336.  
  337. 6  Transit Network Identifier
  338.  
  339. The Transit Network Identifier option of RAP (type 14, format 2, class
  340. any) tags a route as being offered by a particular transit network.
  341. This permits datagram source selection of route(s) traversing or not
  342. traversing the identified network.
  343.  
  344. The data is a domain name, probably the name of the network, although
  345. it may be the name of the organization owning the network,
  346. particularily in the case of a commerical service offering.  It may
  347. also be a domain name assigned specifically for this purpose within
  348. the naming domain of an organization.
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384. Ullmann            DRAFT: expires December 29, 1993            [page  6]
  385.  
  386. Internet draft       Transit Policy Routing in TP/IX       June 30, 1993
  387.  
  388.  
  389. 7  References
  390.  
  391.  [Perl92]    Radia Perlman.  Interconnections:  Bridges and Routers.
  392.                Addison-Wesley.  Reading, Massachusetts.  1992.
  393.  
  394.  [RFC1475]   Robert Ullmann.  TP/IX:  The Next Internet.  Process
  395.                Software Corporation.  June, 1993.
  396.  
  397.  [RFC1476]   Robert Ullmann.  RAP:  Internet Route Access Protocol.
  398.                Process Software Corporation.  June, 1993.
  399.  
  400. 8  Author's Address
  401.  
  402.  
  403. Robert Ullmann
  404. Process Software Corporation
  405. 959 Concord Street
  406. Framingham, MA 01701
  407. USA
  408.  
  409. Phone: +1 508 879 6994 x226
  410. Email: Ariel@Process.COM
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449. Ullmann            DRAFT: expires December 29, 1993            [page  7]
  450.